home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1997 April / EnigmA AMIGA RUN 17 (1997)(G.R. Edizioni)(IT)[!][issue 1997-04][EAR-CD].iso / EARCD / comm / tcp / AmIRCDu2_9_32.lha / AmIRCDu2.9.32 / doc / Operators < prev    next >
Text File  |  1996-05-05  |  9KB  |  243 lines
  1. Internet Relay Chat Operator Etiquette Guide
  2.  
  3. May, 1992
  4.  
  5. Welcome! You've either been selected to be an IRC Operator or you have set
  6. up your server and thus have taken on the dual task of IRC Server
  7. Administrator and IRC Operator. Your future days will be filled with hours
  8. of fun chatting on IRC, and then wondering why everyone you talked to went
  9. away, because the links had apparently broken. 
  10.  
  11. Linking:
  12. ========
  13.  
  14. You will be assigned links from the IRC Routing Coordinators. Please
  15. use these links and these links ONLY. The links have been designed to
  16. maximize efficiency and make delays in chatting minimal. You will
  17. usually be given two links, one to each regional backbone site.
  18. Connect to the primary site first and then to the secondary site. You
  19. should not need to connect to any other sites. You will be informed if
  20. this policy changes.
  21.  
  22. Kills 
  23. =====
  24.  
  25. /kill is a special operator command. You should use it with
  26. care, and only if absolutely needed. The format is as follows:
  27. /kill NICKNAME comment. Comment can be a phrase of almost any length
  28. (within reason) and should be used for specifying the reason of the kill.
  29. Example: /kill Trillian She's a Ghost
  30. IRC Ghosts are created after a net split has occured and the net has yet to
  31. relink. 
  32.  
  33. /wallops PHRASE This is used to talk to those users who have their
  34. user mode set to +w. /wallops used to be a way for operators to talk
  35. about important matters in linking etc., but it has little use
  36. nowadays. 
  37.  
  38. /TRACE command /TRACE is useful to know what servers are connected to
  39. what. Sometimes /trace can be confusing, especially if you are using
  40. it for the first time.  Here is an example of a trace from
  41. stekt1.oulu.fi to cdc835.cdc.polimi.it.
  42.  
  43. /TRACE cdc835.cdc.polimi.it
  44.  
  45. *** Link stekt1.oulu.fi<2.7.2> ==> cdc835.cdc.polimi.it
  46. *** Link rieska.oulu.fi<2.7.1>e ==> cdc835.cdc.polimi.it
  47. *** Link nic.funet.fi<2.7.1>e ==> cdc835.cdc.polimi.it
  48. *** Link ircserver.et.tudelft.nl<2.7.1>e ==> cdc835.cdc.polimi.it
  49. *** Link vesuv.unisg.ch<2.7.1>e ==> cdc835.cdc.polimi.it
  50. *** Link apollo.di.unipi.it<2.7.1>e ==> cdc835.cdc.polimi.it
  51. *** Oper Class[10] ==> Allanon[cdc835.cdc.polimi.it]  
  52. *** User Class[11] ==> Lupandy[plus2.usr.dsi.unimi.it]  
  53. *** Serv Class[3] ==> apollo.di.unipi.it[131.114.4.36] 132S 445C
  54. *** User Class[11] ==> Punk[pluto.sm.dsi.unimi.it]  
  55. *** User Class[11] ==> TheEdge[pluto.sm.dsi.unimi.it]  
  56. *** User Class[10] ==> Mork[cdc835.cdc.polimi.it]  
  57. *** User Class[11] ==> Lollo[c700-2.sm.dsi.unimi.it]  
  58. *** User Class[11] ==> Attila[hp2.sm.dsi.unimi.it]  
  59. *** Class 0  Entries linked 1
  60. *** Class 11 Entries linked 5
  61. *** Class 10 Entries linked 2
  62. *** Class 3  Entries linked 1
  63.  
  64. From this output you can see that the route goes first to
  65. rieska.oulu.fi (running version 2.7.1e), then nic.funet.fi,
  66. ircserver.et.tudelft.nl, vesuv.unisg.ch, and apollo.di.unipi.it, after
  67. which cdc835 is the next server. Then we see the connections on
  68. cdc835: One operator (Allanon) and 6 users are on line. The class of
  69. each connection is given. There is only one server connected to cdc835
  70. at the moment, and that server is apollo.di.unipi.it (cdc835 is said
  71. to be a "leaf" server at the moment). The numbers 132S 445C in the end
  72. of line tell us, that there are 132 servers and 445 clients connected
  73. to the servers from apollo onwards.  Finally we see a grand total of
  74. connections in each connection class. 
  75.  
  76.  
  77. /SQUIT server {comment}
  78.    /squit isolates a specified server from the next closest server, when
  79. you look at it along the trace path starting from your server. 
  80. This is usually used in conjunction with CONNECT (explained later) to
  81. reroute traffic. This will be described in detail in the section
  82. "routing", preceding CONNECT.
  83.  
  84.    Usage (and examples): 
  85.  
  86.       /squit E
  87.  
  88.      If the network looks like this initially (and you are on server A)
  89.  
  90.  
  91.           A <---> B <---> C <---> D
  92.                           ^
  93.                           |
  94.                           v
  95.                   G <---> E <---> F <---> ... (rest of the net)
  96.                           
  97.  
  98.     Then after issuing the previous /squit the network would look like this:
  99.  
  100.           A <---> B <---> C <---> D
  101.                           
  102.                           
  103.                   G <---> E <---> F <---> ...
  104.  
  105.  
  106.     /squit E {comment}
  107.  
  108.     It usually helps to give a reason why you are sending a
  109.     SQUIT for a server. This can be accomplished by sending
  110.     the command "/squit server This link is making the US route
  111.     through Finland". The SQUIT will then be sent out, and the 
  112.     server sending the squit will WALLOP sending the comment
  113.     so all operators can see it. 
  114.  
  115. /CONNECT server {portnum server2}
  116.    /connect is used to establish a link between two servers. These
  117. connections must be authorized by each server's ircd.conf file, but
  118. any operator can issue a CONNECT between authorized servers. This
  119. command is most often used in conjunction with SQUIT to reroute
  120. traffic. 
  121.    If only one argument is given, this command causes the server you
  122. are on to attempt to connect to the server specified. For example,
  123. "/connect B" (in the previous example) would cause your server (A) to
  124. connect to B. 
  125.    Suppose you wanted to reconnect server F to server E? You cannot
  126. contact server F since it is no longer part of your network. However,
  127. you can tell server E to connect to it. A remote CONNECT can be issued
  128. to server E. 
  129.  
  130.    Examples (assume you are on server A):
  131.  
  132.    /connect B
  133.  
  134.    If the network initially looks like this:
  135.  
  136.          A      B <---> ... (rest of network)
  137.  
  138.    Then afterwards (if the connection succeeds) the network will look
  139.    like this:
  140.  
  141.         A <---> B <---> ... 
  142.  
  143.  
  144.    In the example where you wanted to reconnect server E to F, the
  145.    following syntax would be appropriate (note: we are assuming that
  146.    F's irc socket port is 6667, which is the default)
  147.  
  148.    /connect F 6667 E
  149.  
  150.    If the network initially looks like this:
  151.  
  152.          A <---> B <---> C <---> D
  153.                          ^
  154.                          |
  155.                          v
  156.                  G <---> E      F <---> ... 
  157.  
  158.    Then after your CONNECT request the network topology will look like this:
  159.  
  160.          A <---> B <---> C <---> D
  161.                          ^
  162.                          |
  163.                          v
  164.                  G <---> E <---> F <---> ... 
  165.  
  166.     Be careful when connecting servers that you know which command to
  167.     use! If you simply issued "/connect F" from your server, the
  168.     network would look like this:
  169.  
  170.  
  171.     ... <---> F <--->  A <---> B <---> C <---> D
  172.                                        ^
  173.                                        |
  174.                                        v
  175.                                G <---> E 
  176.  
  177.     which for various reasons (discussed below) might be very
  178.     undesirable. 
  179.  
  180. Routing
  181. =======
  182.  
  183.    When and how should you do rerouting? This depends on where your
  184. server is topologically located and whether you route traffic. If you
  185. are a leaf node (i.e. only connect to one server at a time) then
  186. chances are you won't need to do any routing at all.  Your ircd.conf
  187. file should be written to connect to the best possible servers first
  188. before trying alternates. At the most, you may decide to squit an
  189. alternate server and connect to your primary if/when it goes back up.
  190. This only involves local squits, however.
  191.  
  192.    If you are operating a backbone site, you may find yourself
  193. rerouting things quite often. If the servers badger.ugcs.caltech.edu
  194. (Pasadena, CA), irc.mit.edu (Boston, MA), minnie.cc.utexas.edu
  195. (Austin, TX) and ucsu.colorado.edu (Boulder, CO) were routing traffic
  196. in the following way:
  197.  
  198.     ... <---> minnie <---> badger <---> bucsd <---> ucsu <---> ...
  199.  
  200. It would make sense to either squit ucsu and reconnect it to minnie,
  201. or disconnect minnie from badger and connect to ucsu, because
  202. topologically (and geographically) ucsu and minnie are rather close.
  203. There are occasions when US traffic for some reasons winds up being
  204. routed through Australia. This is another case where traffic should
  205. definitely be rerouted. However, there are sometimes occasions when
  206. routing is going through "backdoor" methods. If you see something
  207. totally outrageous (like the east coast and the west coast being
  208. connected by eff.org) please ask for example on channel #twilight_zone
  209. before you send any squits, because chances are, it's like that for a
  210. reason.
  211.  
  212.    Of course, any operator can remotely squit or connect servers, so
  213. if you see a problem and you're sure you know how to fix it, it's a
  214. good idea to do so. If the operator of a server which is is being
  215. routed poorly is online, it's probably best to contact him/her first,
  216. though.
  217.  
  218.    Chances are that hub operators will be more familiar with the
  219. general topology of the network and which servers connect to which
  220. (which is why most of the manual routing is left to them), so if you
  221. have any problems, talk to the other operators on operator channels
  222. (#twilight_zone, #eu-opers etc.) That's what they are there for!
  223.    Also, be aware that servers will notify all the operators online of
  224. remote SQUITs and CONNECTs via WALLOPS.
  225.  
  226. Please let us know if there should be any additions to this guide. Again,
  227. this is not MANDATORY, this is just a GUIDE. Please conduct yourself as 
  228. an IRC Operator would...you are looked upon for assistance, both emotional
  229. and mental. 
  230.  
  231. Helen Rose        Christopher Davis    Noah Friedman
  232. <hrose@cs.bu.edu>    <ckd@cs.bu.edu>        <friedman@ai.mit.edu>
  233.  
  234. January, 1991
  235.  
  236.  
  237. Updated by
  238.  
  239. Mauri Haikola
  240. <mjh@stekt.oulu.fi>
  241.  
  242. May, 1992
  243.